Commercial computer systems presently exist which operate with a host hypervisor control program that supports a plurality of guest operating systems. Examples of such systems include the IBM VM/ESA programming systems for the IBM S/9000 systems. Each guest operates independently of the other guests and perceives that it has the entire system to itself as it executes its programs. Actually, the memory and I/O resources are divided up among the guests. Some resources are shared, and other resources are dedicated to a particular guest. Generally, the one or more CPUs in such a system are shared on a time-slice dispatched basis, although it is possible to dedicate a CPU to a particular guest.
In interpretive execution mode, each of the plural guests perceives that it has its own "real memory", which it uses for the execution of its programs. Each guest's perceived "real memory" is a part of the system's actual real memory (also called "host memory"). Each guest's real memory is mapped into a host virtual memory, from which its addresses can be translated into host real addresses. Thus, a guest's real storage is a part of the host real storage. Essentially, two kinds of mapping are possible: fixed and dynamic. In fixed allocation, a subset of the host real storage is allocated for the guest on a one-for-one basis. The real storage of the guest is dedicated, but its actual host real addresses may be different from what the guest perceives.
An alternative to using a host large virtual address for a V=R or V=FC guest is to map guest real directly onto host real storage. Either mechanism provides the needed constraint on invalid guest CPU accesses.
There are two types of fixed allocations provided in prior art, called respectively, Virtual=Real (V=R) and Virtual=Fixed (V=F). In V=R, the host real addresses of guest real storage are identical to the guest values; only an address limit check is required to constrain the guest to its own storage. Obviously, there can only be one V=R guest in a system. In V=F allocation, a guest real storage is assigned a contiguous set of host real address values equal in size to that assumed by the guest operating system. In guest real to host real address translation (V=F guest), an offset must be applied to the guest real addresses. An address limit check is also necessary. There can be many V=F guests in a system, limited only by the amount of host storage.
The above described guest addressing is disclosed in U.S. Pat. No. 4,843,543 to G. H. Bean et al, assigned to the same assignee as the subject application.
Dynamic allocation of host real storage allows the host to allocate a portion of its real storage to be shared among a set of guests whose performance priority does not require them to be afforded a fixed allocation. For example, such allocation has been judged sufficient for guests that are primarily interactive, with human think time involved in those normal operating scenarios. The dynamic allocation is often called Virtual=Virtual (V=V). Here, allocation occurs at the level of the allocated storage unit of the host, called a page, and the pages of a guest are not assigned to host real until required. The pages assigned for V=V use are allocated by page on demand to execute guest operating systems, and there is no address contiguity requirement. While the guest assumes it has fixed contiguous real storage (the guest virtual storage) assigned for its use, the guest real storage is actually mapped to host virtual storage, and the hypervisor architecture translates guest real addresses through host DAT tables to find the guest page in host real storage. Since assignment is dynamic, page faults are expected in V=V operation (they never occur in V=R or V=F), which causes the host to assign a host page to the referenced guest page, and causes reexecution of the faulting guest instruction. There can be essentially an unlimited number of V=V guests in a system, concurrently.
In the prior art IBM systems, the host and guest virtual memory, and host and guest real memory, each used 31 bit addresses. This invention is concerned with problems caused when the size of these host/guest addresses is greater than 31 bits, and compatibility is desired with programs using the prior 31 bit addresses to enable such prior programs to run on a system using greater than 31 bit addressing (herein called "large addressing").
Large real addressing for a computer system is described and claimed in U.S. patent application Ser. No. 07/754,810 filed on Sep. 4, 1991, and assigned to the same assignee as this application. This application describes how 31 bit guest real addresses can be transformed into larger than 31 bit host addresses, e.g. 63 bit addresses.
Large virtual addressing for a computer system is described in U.S. patent application Ser. No. 07/803,320 now U.S. Pat. No. 5,381,537 filed on Dec. 6, 1991. This application describes how large virtual addresses can be address translated into real addresses using existing translation tables using 31 bit addresses, after which the resulting 31 bit real addresses can be transformed into large real addresses using the teachings of U.S. application Ser. No. 07/754,810.
All of the subject matter of prior-filed applications Ser. Nos. 07/754,810 and 07/803,320 now U.S. Pat. No. 5,381,537 is incorporated herein by reference.
Application Ser. No. 07/754,810 discloses and claims large real addressing (greater than 31 bits, e.g. 63 bits). A resulting real address (i.e. the translated address) obtained from an address translation of a large virtual address (LVA) by the invention in Ser. No. 07/803,329 now U.S. Pat. No. 5,381,537 may be provided as a large real address (LRA) by using the invention in application Ser. No. 07/754,810.
Application Ser. No. 07/803,320 now U.S. Pat. No. 5,381,537 enables the translation of large virtual addresses (LVAs) greater than 31 bits, e.g. 63 bits. The LVAs are generated from instruction operands using large base registers and large size address arithmetic circuits using novel methods and means for handling the part of the address greater than conventional size in combination with conventional types of translation tables to obtain the translation of LVAs into either a small (i.e. conventional size) real address (RA) or a large real address (LRA).
U.S. Pat. No. 4,355,355 (Butwell et al) first disclosed access registers (ARs) for identifying the virtual address space containing an operand. The AR is associated with the base register used in generating the operand. An STD (segment-table designation) is provided as the content of the AR and may be considered an extension of the virtual address of the operand.
U.S. Pat. No. 4,979,098 (Baum et al, PO9-87-004) discloses providing an ALET (access list entry token) in an AR to provide indirection between the AR and the STD associated with the AR. The ALET is comprised of an ALEN, ALESN and P control bit. This indirection secures the AR-associated STD for a user using the AR. AR translation (ART) uses the ALEN (access list entry number) within the ALET in the AR to access an access-list entry (ALE) in an AL (access list) which addresses an ASTE (ASN second table entry) which contains the associated STD.
Application Ser. No. 07/577,395 discloses the Multiple Controlled Data Space (MCDS) Facility which provides common access to data spaces by multiple virtual machine guests emulated on a host computer system. This facility provides MCDS guests, which are a special form of V=V guests that operate without guest DAT and have access, by means of ALET-qualified 31-bit guest real addresses, to data spaces created and managed by the host. The ALET-qualified 31-bit guest real addresses are contained in access and general register pairs, and are translated through host ART and DAT processes and tables to find the data pages in host real storage.